NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/1602

Internet Message Format | 1996-08-06 | 4.1 KB

Path: engnews2.Eng.Sun.COM!usenet
From: [e-mail] (Nitin More [CONTRACTOR])
Newsgroups: comp.lang.c++
Subject: Re: IsA v/s HasA problem
Date: 11 Jan 1996 20:56:52 GMT
Organization: SunSoft
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: more.eng.sun.com
In-reply-to: Saurabh Dixit's message of Thu, 11 Jan 1996 15:27:34 GMT

In article <[e-mail]> Saurabh Dixit <[e-mail]> writes:

>   Newsgroups: comp.lang.c++
>   From: Saurabh Dixit <[e-mail]>
>   Organization: Compaq Computer Corporation
>   Date: Thu, 11 Jan 1996 15:27:34 GMT
>   X-Nntp-Posting-Host: 172.18.176.8
>
>   Hi!
>
>   I always had no trouble distinguishing between the two...
>
>   But now, I for a specific case, I fail to see the repercussions of
>   using the wrong relationship between objects.
>
>   This is my scenario.
>   I have an object of type Base.  This is an abstract class.
>   From Base I derive several different objects.
>   I want to maintain a list of such objects for which I have a class
>   Collection that encapsulates a typed array of Base objects.
>
>   I now want to define an object - let's call it Duh - that maintains a
>   collection of Base objects.  Duh objects are entities on their own and could
>   have other attributes, BUT NEVER ANOTHER COLLECTION.
>
>   From what I gather, I am then leaning towards a HasA relationship, i.e.
>   class Collection
>   {
>   public:
>       BOOL Add (Base* b);
>   };
>   class Duh
>   {
>   private:
>       Collection c;
>   };
>
>   Obviously if I was going to have 2 or more collections, then I would have had
>   to have a HasA relationship.  But as said earlier, this is not the case!
>   Also, I want to have some operations common between Collection and Duh.
>   e.g. I can Add() a Base (derived!) object to a Collection and I also want
>   to Add() an object to Duh.  In a HasA relationship I would simply
>   implemenent this as follows.
>   BOOL Duh::Add (Base* b)
>   {
>       // simply pass on to Collection method
>       return c.Add (b);
>   }
>   However for an IsA relationship, I would simply do
>   class Duh : public Collection
>   {
>   };
>   and I am done.
>
>   Am I wasting my time too much thinking about this?  Regardless of code
>   implementation, from the logical perspective, what is the correct object-
>   oriented solution for my problem, HasA or IsA?
>
>   Any help will be greatly appreciated
>   thanks
>   saurabh
>   --
>   Saurabh Dixit
>   "All opinions are always my own..."
>   Compaq Computer Corporation
>   ------------------------------------------------------------------------
>   Thou who sneezes without kerchief takes matters in own hands.
>               - SomeoneIOnceNew
>   ------------------------------------------------------------------------
>   xxxx
>

IsA or HasA releationship (in this example) depends on what other things Duh
does.  Is it adding more functionality to the Collection?  For example, it
could have additional attributes to keep track of highest/lowest value in the
collection, or provide methods to operate on the Collection.  In this case use
the IsA relationship AND DON'T add more things to Duh which has nothing to do
with the Collection.  Define another class for that.  Keep your classes small
and simple with a well defined purpose.  Don't overload it.

If Duh needs to keep a Collection for other things that it needs to do then
use the HasA relationship.

Another approach is to ask yourselves whether somebody can use the class Duh
in place of the Collection class (with improved functionality)?  If yes, then
use the IsA relationship.

If you keep your classes small and simple with well defined purpose then it is
easy to choose between IsA and HasA relationship.

Hope this helps.

-Nitin
--
----------------------------------------------------------------------
Nitin More
SunSoft, Bldg 16  Off: [phone]
Menlo Park, CA    Fax: [phone]   e-mail: [e-mail]
----------------------------------------------------------------------